Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/answers/comp/motif-faq/part4

Text File | 1994-04-14 | 64KB | 1,494 lines

Path: bloom-beacon.mit.edu!grapevine.lcs.mit.edu!olivea!charnel!charnel.net.csuchico.edu!nic-nac.CSU.net!usc!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!cs.umd.edu!kong.gsfc.nasa.gov!kong.gsfc.nasa.gov!not-for-mail
From: [e-mail] (Brian Dealy)
Newsgroups: comp.windows.x.motif,news.answers,comp.answers
Subject: Motif FAQ (Part 4 of 5)
Followup-To: poster
Date: 14 Apr 1994 15:20:37 -0400
Organization: NASA/Goddard Space Flight Center
Lines: 1476
Approved: [e-mail]
Distribution: inet
Expires: +1 months
Message-ID: <2ok525$[e-mail]>
Reply-To: [e-mail] (Brian Dealy)
NNTP-Posting-Host: kong.gsfc.nasa.gov
Keywords: FAQ question answer
Xref: bloom-beacon.mit.edu comp.windows.x.motif:15729 news.answers:18060 comp.answers:4911


Archive-name: motif-faq/part4
Last-modified: APR 04, 1994
Version: 3.6






-----------------------------------------------------------------------------
Subject: 96)  TOPIC: XMSTRING

-----------------------------------------------------------------------------
Subject: 97)  How can I get the Ascii text out of an XmString?

Answer: To get the first line of text from a string created left-to-right


        char *str;
        XmString xmstr;

        /* stuff to create xmstr */
        ...

        /* set str to point to the text */
        XmStringGetLtoR(xmstr, XmSTRING_DEFAULT_CHARSET, &str);
        /* use the string */
        ...

        /* and reclaim space */
        XtFree(str);


-----------------------------------------------------------------------------
Subject: 98)  When can XmStrings used as resources be freed?

Answer: The policy OSF have been trying to enforce is that if you set an
XmString or XmStringTable resource, the application is responsible for freeing
the XmStrings used because the widget makes a copy.  If you get an XmString
resource, then the application must free the value gotten.  If you get an
XmStringTable, then the application should NOT free the value gotten.  If the
application wants to manipulate it, it should make a copy first. This policy
appears to be implemented progressively, so may be less true for Motif 1.0
than 1.1.

-----------------------------------------------------------------------------
Subject: 99)  Why doesn't XmStringGetNextSegment() work properly?

Answer: The documentation in Motif 1.0 is in error. Instead of

        XmStringGetnextSegment(context, ...)
        XmStringContext * context;

it should be

        XmStringGetnextSegment(context, ...)
        XmStringContext context;

i.e. with no indirection.


-----------------------------------------------------------------------------
Subject: 100)  Why does using XmStringDraw cause a Bad Font error?

[Last modified: May 93]

Answer: From Thomas Berlage ([e-mail]): You could call this a bug
in Motif. You pass a GC to XmStringDraw, however, Motif wants to use the fonts
from the font list to draw the string.  Therefore it replaces the font of the
GC temporarily with some fonts of its own as specified in the font list. In
the end it tries to restore the old font of the GC. There comes the problem:

If a GC uses the default font, the client side GC structure does not have a
valid font id (that is the 0xffffffff you may see in the error message). Motif
tries to restore this invalid id at the end.

The workaround is: Before drawing with XmStringDraw, set the font id of the GC
to any valid font id, for example using

      XSetFont (display, gc, XLoadFont (display, "fixed"));




-----------------------------------------------------------------------------
Subject: 101)  TOPIC: DIALOGS

-----------------------------------------------------------------------------
Subject: 102)  How do I stop my dialog disappearing when I press the help
button?

Answer: Bulletin board has the resource autoUnmanage which defaults to True.
This unmanages the widget when any button child is activated - including the
help button.  Set this to False to stop it disappearing. Note that you then
have to unmanage the bulletin board yourself when any other button is
activated.

-----------------------------------------------------------------------------
Subject: 103)  How do I make my own dialog?  I want a dialog with my own set
of buttons that stretch and shrink like the ones in e.g. PromptDialog and its
own contents.

Answer: Start off with say a PromptDialog. Unmanage the buttons you don't want
or manage the Apply button if you want another. Unmanage the other bits of the
selection box you don't want. You can add another WorkArea child to the
selection box for any extra stuff you want.

    /* Copyright 1990, Kee Hinckley and Brian Holt Hawthorne */
    /* Permission granted for any use, provided this copyright */
    /* notice is maintained. */

    /* Create a dialog box */
    argcount = setArgs(&args, XmNautoUnmanage, False, NULL);
    SomeDialog = XmCreatePromptDialog(mainShell, "someDialog", args, argcount);

    /* Now get rid of the things we don't want */
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_SELECTION_LABEL);
    XtUnmanageChild(child);
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_TEXT);
    XtUnmanageChild(child);

    /* set the callbacks, and make sure the buttons we want are there */
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_OK_BUTTON);
    XtAddCallback(child, XmNactivateCallback, callSomeFunc, someArg);
    XtAddCallback(child, XmNactivateCallback, unManage, SomeDialog);
    XtManageChild(child);
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_APPLY_BUTTON);
    XtAddCallback(child, XmNactivateCallback, callSomeFunc, someOtherArg);
    XtManageChild(child);
    child = XmSelectionBoxGetChild(SomeDialog, XmDIALOG_CANCEL_BUTTON);
    XtAddCallback(child, XmNactivateCallback, dialogUnmanage, SomeDialog);
    XtManageChild(child);

    /* Add a new work area. This can be any manager. */
    child = XmCreateForm(SomeDialog, "someForm", NULL, 0);
    XtManageChild(child);

    /* and fill it up... */
    something = doYourStuff(child);

another Answer:

        I had a some people asking about my xmSmartMessageBoxWidget

        It's public domain, and needs Motif-1.2  and is available at
        ftp.x.org:/contrib/widget/SmartMB.tar.Z.

        The basic idea behind it is that it allows the programmer to
        specify the management of child widgets in 4 areas: Label, Control,
        Separator and Action.  You can have up to 1 Label, 1 Control,
        1 Separator and as many Action children as you want.  It does not
        REQUIRE any of these, and there is no unmanaging of extra widgets,
        as the programmer creates what is needed.

        Thanks for the smart dialog info to:         John L. Cwikla
        Wolfram Research, Inc.          [e-mail]




-----------------------------------------------------------------------------
Subject: 104)  How come the title bars for my dialogs now have "_popup" or
"<-popup" concatenated onto the widget name?


Answer: Motif 1.0.3 (?) "fixed" things such that title bars without an
explicit dialogTitle setting use the widget name with "_popup" or whatever
added on.  Set the dialogTitle resource explicitly if you don't want this new
default naming scheme.

-----------------------------------------------------------------------------
Subject: 105)  How can I force a dialog window to display?  I manage a
"working" dialog, and do some computing, but the dialog window appears blank
until the work has finished.  How can I force it to be displayed?

Answer: Use this.  (David Brooks, Systems Engineering, Open Software
Foundation)

/*
 * This procedure will ensure that, if a dialog window is being mapped,
 * its contents become visible before returning.  It is intended to be
 * used just before a bout of computing that doesn't service the display.
 * You should still call XmUpdateDisplay() at intervals during this
 * computing if possible.
 *
 * The monitoring of window states is necessary because attempts to map
 * the dialog are redirected to the window manager (if there is one) and
 * this introduces a significant delay before the window is actually mapped
 * and exposed.  This code works under mwm, twm, uwm, and no-wm.  It
 * doesn't work (but doesn't hang) with olwm if the mainwindow is iconified.
 *
 * The argument to ForceDialog is any widget in the dialog (often it
 * will be the BulletinBoard child of a DialogShell).
 */

ForceDialog(w)
     Widget w;
{
  Widget diashell, topshell;
  Window diawindow, topwindow;
  Display *dpy;
  XWindowAttributes xwa;
  XEvent event;
  XtAppContext cxt;

/* Locate the shell we are interested in.  In a particular instance, you
 * may know these shells already.
 */

  for (diashell = w;
       !XtIsShell(diashell);
       diashell = XtParent(diashell))
    ;

/* Locate its primary window's shell (which may be the same) */

  for (topshell = diashell;
       !XtIsTopLevelShell(topshell);
       topshell = XtParent(topshell))
    ;

  if (XtIsRealized(diashell) && XtIsRealized(topshell)) {
    dpy = XtDisplay(topshell);
    diawindow = XtWindow(diashell);
    topwindow = XtWindow(topshell);
    cxt = XtWidgetToApplicationContext(diashell);

/* Wait for the dialog to be mapped.  It's guaranteed to become so unless... */

    while (XGetWindowAttributes(dpy, diawindow, &xwa),
           xwa.map_state != IsViewable) {

/* ...if the primary is (or becomes) unviewable or unmapped, it's
   probably iconified, and nothing will happen. */

      if (XGetWindowAttributes(dpy, topwindow, &xwa),
          xwa.map_state != IsViewable)
        break;

/* At this stage, we are guaranteed there will be an event of some kind.
   Beware; we are presumably in a callback, so this can recurse. */

      XtAppNextEvent(cxt, &event);
      XtDispatchEvent(&event);
    }
  }

/* The next XSync() will get an expose event if the dialog was unmapped. */

  XmUpdateDisplay(topshell);
}


-----------------------------------------------------------------------------
Subject: 106)  How can I control placement of a popup widget?  Each time a
popup is created, it is placed in or over the middle of its parent.  How can I
make it obey the XmNx and XmNy values?

Answer: Set the resource XmNdefaultPosition for the popup to False.  Set the
position of the popup by the resource values of XmNx and XmNy.  Do not use
XtMoveWidget, as this is for widget writers only.  Here's a demo program from
Dan Heller:

/* Written by Dan Heller.  Copyright 1991, O'Reilly && Associates.
 * This program is freely distributable without licensing fees and
 * is provided without guarantee or warranty expressed or implied.
 * This program is -not- in the public domain.  This program is
 * taken from the Motif Programming Manual, O'Reilly Volume 6.
 */

/* map_dlg.c -- Use the XmNmapCallback to automatically position
 * a dialog on the screen.  Each time the dialog is displayed, it
 * is mapped down and to the right by 200 pixels in each direction.
 */
#include <Xm/MessageB.h>
#include <Xm/PushB.h>

/* main() --create a pushbutton whose callback pops up a dialog box */
main(argc, argv)
char *argv[];
{
    Widget toplevel, button;
    XtAppContext app;
    void pushed();

    toplevel = XtVaAppInitialize(&app, "Demos",
        NULL, 0, &argc, argv, NULL, NULL);

    button = XtCreateManagedWidget("button", xmPushButtonWidgetClass,
        toplevel, NULL, 0);
    XtAddCallback(button, XmNactivateCallback, pushed, "Hello World");

    XtRealizeWidget(toplevel);
    XtAppMainLoop(app);
}

/* callback function for XmNmapCallback.  Position dialog in 200 pixel
 * "steps".  When the edge of the screen is hit, start over.
 */
static void
map_dialog(dialog, client_data, cbs)
Widget dialog;
XtPointer client_data;
XmAnyCallbackStruct *cbs;
{
    static Position x, y;
    Dimension w, h;

    XtVaGetValues(dialog, XmNwidth, &w, XmNheight, &h, NULL);
    if ((x + w) >= WidthOfScreen(XtScreen(dialog)))
        x = 0;
    if ((y + h) >= HeightOfScreen(XtScreen(dialog)))
        y = 0;
    XtVaSetValues(dialog, XmNx, x, XmNy, y, NULL);
    x += 200, y += 200;
}

/* pushed() --the callback routine for the main app's pushbutton.
 * Create and popup a dialog box that has callback functions for
 * the Ok, Cancel and Help buttons.
 */
void
pushed(w, message)
Widget w;
char *message; /* The client_data parameter passed by XtAddCallback */
{
    Widget dialog;
    Arg arg[3];
    XmString t = XmStringCreateSimple(message);
    extern void response();

    XtSetArg(arg[0], XmNautoUnmanage, False);
    XtSetArg(arg[1], XmNmessageString, t);
    XtSetArg(arg[2], XmNdefaultPosition, False);
    dialog = XmCreateMessageDialog(w, "notice", arg, 3);
    XmStringFree(t);

    XtAddCallback(dialog, XmNmapCallback, map_dialog, NULL);

    XtManageChild(dialog);
    XtPopup(XtParent(dialog), XtGrabNone);
}


-----------------------------------------------------------------------------
Subject: 107)  TOPIC: LANGUAGE BINDINGS

-----------------------------------------------------------------------------
Subject: 108)* Is there a C++ binding for Motif?

[Last modified: May 93]


Answer: WWL is a library which defines C++ classes around X Toolkit Widgets.
It is intended to simplify the task of C++ code writers when using the Toolkit
by providing them with C++ objects, methods, type checking and several utility
functions and classes.

WWL has been tested under SunOs4.0.3 on sun3 and sun4, HPUX version 6.5 and
7.0 and Ultrix 4.0 on DECstation 3100 and 5000. It is expected to work on most
other UNIX systems without too many problems.

WWL is distributed as a tar file with all the source, documentation and
example. The file is available using anonymous ftp from

        export.lcs.mit.edu (18.30.0.238   contrib/WWL-1.0.tar.Z
        lri.lri.fr (129.175.15.1)      pub/WWL-1.0.tar.Z


Answer: Rogue Wave Software has a C++ binding for Motif called View.h++.

"View.h++ is a complete C++ interface to OSF/Motif.  It doesn't just
encapsulate it, but also includes a set of classes that provide a level of
abstraction above Motif, thus simplifying menu and dialog creation, XmStrings,
XmFontLists, etc.  View.h++ supports a Model- View-Controller architecture,
allowing for an even more object-oriented interface design.  Includes a copy
of Rogue Wave's Tools.h++ (foundation class library)"

An object license is $795 "per seat" and a source code license is available
for $2,995 "per seat."  Rogue Wave also offers full support for View.h++.

It is currently available for Sun Sparc, IBM RS/6000, HP 9000/700 series, SCO,
Intel SVR4 ESIX.  Please call for Silicon Graphics and DEC Ultrix status.

For additional information, please contact:

Matt Steinauer
Rogue Wave Software, Inc.
P.O. Box 2328
Corvallis, OR 97339
Phone: [phone]
Fax:   [phone]

email:   [e-mail]


Answer: Builder Xcessory 3.0, an interface builder from ICS, allows the user
to visually build C++ classes from Motif and user-written widgets.  C++ code
is generated in the "Doug Young" fashion.  (Doug actually worked on this
project with ICS.)  C and UIL can also be generated.

Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA  02139
USA [e-mail]   617/621-0060



Answer: From [e-mail]: The GINA++ application framework contains
an encapsulation of the OSF/Motif widg et classes and the Xt functionality
into C++ classes. Its functionality is comparab le to that of the ULowell
binding and the WWL. Additionally, it provides an easy-to -use framework for
modeling new composite and primitive widget classes, plus an application
framework similar to ET++ or MacApp build on top of it. The binding may be
used independently from the framework classes. GINA++ is available through
anonymous ftp from ftp.gmd.de [129.26.8.90] in the directory /gmd/ginaplus.
Documentation about the Motif binding has been published in the X Resource
Journ al, Number 2, 1992, Pages 106-130. The binding compiles with AT&T C++
2.1 and GNU G+ + 2.1 and has been tested on SunOS 4.1.[12], X11R4 and Motif
1.1.3.

Answer: Motif++ is a library that defines C++ class "wrappers" for the widgets
defined in the X11R5 OSF/Motif-1.2 widget library.  It also supports
X11R4/Motif-1.1 as well.

Motif++ is also an application toolkit that provides other tools in
conjunction with the widget wrapper classes.  It has support for the Xbae
widget set, plus other widgets.  It has Imake support, and lots of test files.
Motif++ also has alot of contributed software.


Motif++ is very similar to other public domain widget libraries such as The
Widget Wrapper Library (WWL) and the C++ Binding for OSF/Motif developed at
the University of Lowell. The two latter libraries are the result of much
larger efforts.

Availability:

Anonymous ftp at decuac.dec.com (192.5.214.1), directory /pub/X11,
file motif++.28.jul.93.tar.Z

For more information, contact Ronald van Loon ([e-mail]).
There is also mailing list for Motif++. Send e-mail to

Answer: Xm++ is a user interface framework for the C++ language built upon X11
and the X-Toolkit. It is designed to be a simple and intuitive programming
interface to access the functionality of commonly used widgets.  Xm++ was
initially created for the Motif widget set, now support for the Athena widgets
was added. Applications created with Xm++ run in both environments without
changes, although many nice features are only available when using Motif.

Xm++ is available on: export.lcs.mit.edu as: /contrib/Xm++.0.5.tar.Z

Answer: The Solbourne OI toolkit (not Motif) also has a C++ binding.

Answer: Liant have C++/Views.

Answer: Quest have ObjectViews.  Answer: Builder Xcessory 3.0, an interface
builder from ICS, allows the user to visually build C++ classes from Motif and
user-written widgets.  C++ code is generated in the "Doug Young" fashion.
(Doug actually worked on this project with ICS.)  C and UIL can also be
generated.

Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA  02139
USA [e-mail]   617/621-0060


Answer: Doug Young has written a book "Object Oriented Programming with C++
and Motif", Prentice-Hall ISBN 0-13-630252-1 about using C++ without requiring
one of these toolkits.

Answer: Unfortunately, this library (last released in 9/92) has the same name
as the one by Ronald van Loon ([e-mail]).

Motif++1.2 is a library that defines C++ class "wrappers" for the widgets
defined in the OSF/Motif-1.1 widget library.  Motif++1.2 is also an
application toolkit that provides other tools in conjunction with the widget
wrapper classes.
    One enhancement of Motif++1.2 beyond its wrapper classes are the addition
of an "application" class which takes care of the low-level tasks including
initializing X, creating and managing one or more top-level shells, and
entering the main event loop.
    Another feature of Motif++1.2 is its integration with The Widget Creation
Library (Wcl).  Motif++1.2 makes it easy to initialize Wcl and create C++
wrappers for desired widgets in the widget tree.
    Availability: anonymous FTP at ftp.arc.umn.edu (137.66.130.11), file
pub/Motif++1.2.tar.Z.  Contact Paul Felix, [e-mail] or
[e-mail].

submitted by: mvc![e-mail] ( Mark R. Biggers )

-----------------------------------------------------------------------------
Subject: 109)  How can I have a C++ member function in a callback?

[Last modified: October 93]
Answer: There are three common user problems with C++ callbacks.  First, make
sure you use the correct function prototype for the function declarations.
Second, the callback function must be declared as a static member of the
class.  Third, when registering it with XtAddCallback(), you must use its full
signature.  For example: (Ken Lee [e-mail])

    class MyClass {
        ...
        void createWidgets();
        static void myButtonCB(Widget, XtPointer, XtPointer);
        ...
    };
    void MyClass::createWidgets() {
        ...
        w = XtCreatePushButton(...);
        XtAddCallback(w, XmNactivateCallback, &MyClass::myButtonCB,
            (XtPointer) this);
        ...
    }
    void myButtonCB(Widget w, XtPointer clientData, XtPointer callData) {
        MyClass *myclass = (MyClass *) clientData;
        ...
    }

Note that the "this" pointer is used as the client data.  This technique is
popular, but not required.


Motif++ has a nice tutorial summarising mechanisms (this is available
separately by email from Ronald van Loon ([e-mail])). Doug
Young's book deals extensively with one of these. The problem is that you
don't get the object when you just use the function as a callback.  You need
to pass the object as a pointer through as the client_data.  (use "this" as
the client_data.) Then you can retrieve the object's address, and dereference
from there. For example (Leo O'Donnell, Email: [e-mail]),

    class MyButton {
      public:
                MyButton (Widget parent, const char *name) {
                    _button = XtVaCreateManagedWidget (
                        name, xmPushButtonWidgetClass, parent, NULL, 0);
                    XtAddCallback (
                        _button,
                        XmNactivateCallback,
                        &MyButton::activateCB,
                        (XtPointer) this);
                }
                ~MyButton () { XtDestroyWidget (_button); }
      private:
        Widget  _button;
        static  void activateCB (Widget, XtPointer, XtPointer);
    };

    void MyButton::activateCB (Widget, XtPointer thisBtn, XtPointer)
    {
        MyButton *btn = (MyButton *) thisBtn;

        // OK you've got the button instance now. Do some stuff with it!
    }



-----------------------------------------------------------------------------
Subject: 110)  Is there a Common Lisp binding for Motif?

[Last modified: November 92]

Answer: Try CLM. This includes a toolkit demon (in C) that takes a widget
description (with callbacks), and forks a new process for each Motif
application (which can be just a single menu, or whatever).  Lisp can then
continue running, with a separate lightweight lisp process handling the
connection & callbacks.  In North America & net environs, CLM-2.0beta is
available from export.lcs.mit.edu.

There is also CLIM, the Common Lisp Interface Manager. It provides access to
motif and other toolkits and window systems.  Here is some blurb: "Version 2.0
of the Common Lisp Interface Manager (CLIM) provides access to Motif. CLIM is
the emerging standard for GUI development in Common Lisp.  It offers a set of
high-level facilities that enable rapid construction of user interfaces.
Applications written using CLIM are portable across a variety of window
systems and toolkits.  For example, on the X window System, both Motif
(OSF/Motif) and Openlook (OLIT) are supported.  CLIM accesses the toolkit
directly rather than emulating the look and feel."

CLIM is available from a variety of Common Lisp vendors including Symbolics
and Franz Inc. ([e-mail]).


-----------------------------------------------------------------------------
Subject: 111)* Is there an Ada binding for Motif?

[Last modified: Apr 94 ]

Answer:

Answer:  Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to
Motif for a number of platforms and Ada compilers.  ICS also provides Builder
Xcessory, a Motif interface builder, which outputs Ada code usable with the
Ada bindings.  The product family is known collectively as the Ada Xcessories.

Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA  02139
USA [e-mail]   617/621-0060



Information on Ada bindings to Motif and other services (such as SQL and
POSIX) can be found in a document maintained by the Ada Information
Clearinghouse.  The report can be found at

        host:   ajpo.sei.cmu.edu
        loc:    /public/ada-info/bindings.hlp.*
        access: anonymous ftp

The suffix to the file (indicated above with an asterix) is the date of the
latest update to the document.  For example, the full name of the report
updated on 14 June 1993 would be

        /public/ada-info/bindings.hlp.14Jun93.

The file is ASCII.

------ Included File


[...Excerpted from the AdaIC report bindings.hlp.14Jun93...]
[...Updates can be found on ajpo.sei.cmu.edu, in the    ...]
[...file /public/ada-info/bindings.hlp.*  The suffix    ...]
[...is always the date of the lastest version to the    ...]
[...report.                                             ...]

                                     SECTION 12
                                  X-Window System:
                               OSF Motif and Open Look
                               Available Ada Bindings


12.1  Description and Standardization Efforts

The X-Window System is a network-transparent window system.  It supports one
or more screens containing overlapping windows or subwindows.  X display
servers distribute user input to and accept output requests from various
client programs located either on the same machine or elsewhere in the
network.

            OSF Motif (Open Software Foundation/Motif) is a graphical user
            interface from OSF that provides a Presentation Manager look and
            feel for applications running on any system with X Window version
            11.  It conforms to POSIX, ANSI C and X/Open's XPG3 standards.

12.2  Resources Available from Software Reuse Libraries/Repositories


ASSET                                                      (Updated:  November
1 992)

The following information was taken in its entirety from the ASSET Library
Repository Catalog, October 9, 1992.  For more information on ASSET, see
Appendix C.


INTERFACE TO THE X WINDOW SYSTEM

VERSION_NUMBER    : 1.1
DEVELOPED_BY      : SAIC
RELEASE_DATE      : 29-SEP-88
UNIQUE_IDENTIFIER : ASSET_A_240
ALTERNATE_NAME    : SAICX2
ASSET_TYPE        : SOFTWARE CODE
FUNCTIONS         : INTERFACE, BIND
OBJECTS           : ADA, X WINDOWS
KEYWORDS          : STANDARDS, BINDINGS
COLLECTION        : STARS FOUNDATIONS
DISTRIBUTION      : UNLIMITED

DESCRIPTION       :

Interface to the X Window System
      An expression of the various concepts in Ada that provides a full,
working Ada specification of the X Window system.
     Approved for public release; distribution is unlimited.

12.3  Products Available from Vendors


Advanced Technology Center                                 (Updated:  November
1 992)

The Advanced Technology Center (ATC) has an Ada binding to OSF Motif for their
AXI~ product.  AXI is currently available for most UNIX-based platforms, and
is supported by Verdix, Meridian, and TeleSoft compilers.

AXI is an Ada-to-X-Window System interface that provides the Ada programmer
access to the 500+ functions, libraries, and procedures contained in the X
library (Xlib), the X Toolkit (Xt), the X Extensible Library, the X
Miscellaneous Utilities, the Motif widget set and the Motif Resource Manager.

ATC is planning to develop an Ada binding to Open Look for AXI.

For more information, contact:Larry Paulson, Advanced Technology Center, 22982
                        Mill Creek Drive, Laguna Hills, CA  92653, USA; Phone:
                        714-583-9119


Alsys, Inc.                                                     (Updated:  May
1 992)

The Alsys Ada Software Development Environment (Alsys's validated Ada compiler
#901221W1.11103) for 386 UNIX is a production-quality Ada environment capable
of handling very large Ada applications (over 500,000 lines of code).  The
product includes the Compiler; Multi-Library Environment, which provides a
powerful and flexible way to manage Ada development effort and share program
units; Binder, which supports unused subprograms elimination; High-and Low-
Level Optimizers for improving code quality and performance; and Run-Time
Executive for efficient support for executing Ada programs.  Also included is
the Developer's Toolset including:  Ada Probe, a symbolic source level
debugger and program viewer; AdaXref, a cross-reference generator; AdaMake, a
recompilation aid; AdaReformat, a source reformatter.

Alsys currently has Ada bindings to POSIX, X-Windows (OSF Motif), and the
Generic Package of Elementary Functions for the Alsys Ada Software Development
Environment, running on 386 UNIX 386/486-based machines supported as both host
and target and running 386/ix or SCO UNIX.  They are also planning a binding
to SQL for  386/486 machines.

Host/Target:386/486 PC under IX UNIX, 386/486 PC under SCO UNIX

The Alsys Ada Software Development Environment for the IBM RS/6000 is a
production-quality Ada environment capable of handling very large Ada
applications.  Hosted on and targeted to the IBM RS/6000 workstation under
IBM's AIX operating system, the product includes the Compiler; Multi-Library
Environment, which provides a  powerful and flexible way to manage Ada
development efforts and share program units; Binder; Run-Time Executive; and
both a High and Low-Level Optimizer for improving code quality and
performance.  Also included is the Alsys Ada Toolset including Ada Probe,
symbolic source level debugger and program viewer; AdaXref, cross-reference
generator; AdaMake, recompilation aid; and AdaReformat, source reformatter.

Alsys has bindings currently available to the Generic Package of Elementary
Functions and to X-Windows (OSF Motif) for the Alsys Ada Development
Environment for the IBM RS/6000 running on any RISC System/6000 machine as
both host and target and running IBM's AIX operating system (Alsys's validated
Ada compiler #910809W1.11195).   Alsys also plans to develop a POSIX binding
for the RS/6000.

Host/Target:RISC System/6000 under AIX

The Alsys Ada Software Development Environment for SPARC Workstations is a
production-quality Ada environment capable of handling very large Ada
applications.  Hosted on any SPARC-based workstation under SunOS or SunView,
the product helps you realize the full potential of Ada on SPARC machines. The
product includes the Compiler (with High- and Low-Level Optimizers); Binder,
which supports unused subprogram elimination; Multi-Library system (Family,
Library, and Unit Managers) which provides a powerful and flexible way to
manage Ada development efforts and share program units;  AdaExec real-time
executive, for complete and efficient support for executing Ada programs; and
ISO-standard mathematical library.  Also included is the Alsys Ada Toolset
including AdaProbe, symbolic source level debugger and program viewer;
AdaXref, cross-reference  generator; AdaMake, recompilation aid; and
AdaReformat, source reformatter.

Bindings to the Generic Package of Elementary Functions and to OSF/Motif are
currently available for the Alsys Ada Software Development Environment running
on any SPARC-based Workstation as both host and target and running SunOS or
SunView.

Host/Target:SPARC under SUNOS

For more information, contact:Scott Garren, Alsys, Inc., 67 South Bedford
                        Street, Burlington, MA  01803-5152, USA;  Phone:
                        [phone]


Digital Equipment Corporation                              (Updated:  November
1 992)

Digital Equipment Corporation has bindings available for GKS, PHIGS, SQL, and
OSF Motif for VAX Ada/VMS.  The Ada bindings are provided either as part of a
compiler product or the services/facilities that are provided by Digital and
its suppliers.

Host/Target:DEC VAX under VMS

For more information, contact:Mary Anne Cacciola, Digital Equipment
                        Corporation, 110 Spit Brook Road, Nashua, NH  03062,
                        USA; Phone:  [phone]


IBM                                                        (Updated:  November
1 992)

IBM's AIX Ada/6000 product provides a binding to GPEF and IBM AIXWindows (X-
Windows ... not Motif).  It runs on all models of the IBM RISC System/6000
under the IBM AIX Version 3.2 operating system. See also entries for Systems
Engineering Research Corporation (SERC) and Advanced Technology Center (ATC)
for Motif, GKS or PHIGS bindings for use with IBM AIX Ada/6000 products.


The AIX Ada/6000 licensed programs (5706-291 and 5706-294) consist of an
optimizing compiler, a run-time environment, a symbolic debugger, an Ada
"makefile" generator for use in automating and minimizing recompilation, Ada
library management tools and Ada language bindings to some key AIX subsystems.
With the exception of some system-specific aspects of the language, the Ada
language for the AIX operating system is source compatible with the Ada
language supported by IBM licensed programs in VM/CMS and MVS.

Host/Target:IBM RISC System/6000 under the IBM AIX Version 3.2 operating
            system

This product conforms to the following standards:  ANSI/MIL-STD-1815A - Ada at
current level (1.11) of the ACVC test suite.

For more information, contact:Barry Lee, IBM Corporation, 844 Don Mills Road,
                        North York, Ontario, Canada  M3C 1V7; Phone:  (416)
                        448-3174; Fax: [phone]

Objective Interface Systems, Inc.                          (Updated:  November
1 992)

Objective Interface Systems, Inc., has an Ada binding to X-windows (OSF Motif)
for its Screen Machine~ product.  The Screen Machine binding to Motif includes
a WYSIWYG drawing tool and an Ada code generator.

Host/Target:

      Sun SPARC/SunOS         Rational R1000/Delta    HP 9000/7XX; 8X7
      IBM RISC System/6000/AIXPC 386/486/ISC UNIX     HFSI WIS Workstation
      PC 286/386/486/MS-DOS   PC 386/486/SCO UNIX     DEC Ultrix; DEC VMS

For more information, contact:Phil Carrasco, Object Interface Systems, Inc.
                        1895 Preston White Drive, Suite 250, Reston, VA
                        22091-5448, USA; Phone: [phone]; Fax:
                        703-264-1721; email [e-mail] (internet)


SL Corporation                                              (Updated: November
1 992)

SL Corporation's SL-GMS toolkit includes Ada bindings to GPEF, GPPF, POSIX,
SQL, TCP/IP, OSF/Motif, and Open Look.

SL-GMS is a toolkit for developing dynamic graphics screens for real-time or
highly interactive applications.  Non-programmers can design application
screens in a standard drawing-tool mode, connect them to real-time data
sources and animate screen objects to visualize changing data values.  SL-GMS
allows the design of custom "GISMOs" to input values or control the
application and supports MOTIF, OPEN LOOK and other X toolkit widgets.

SL-GMS is used extensively to provide real-time graphics for applications in
the fields of manufacturing, process control, network management, avionics and
financial tracking.

Host/Target:Validated Verdix and DEC compilers support SL-GMS for the
            following machines as both host and target:


      DEC-DECstation/ULTRIX 4.0DEC-VAXstation/ULTRIX 4.0
      DEC-VAXstation/VMS 5.4  DEC-VAXstation/VMS 5.5

      IBM-RS6000/AIX

      HP-9000/300/UNIX        HP-9000/400/UNIX
      HP-9000/800/UNIX        HP-9000/700/UNIX

      PC-386/IX UNIX          PC-386/SCO UNIX
      PC-386/Lynx             PC-386/0S2
      PC-386/System 5.4

      SGI-4D/IRIX 3.3

      Sun-3/SunOS 4.1         SunSPARC/SunOS 4.1

      88 Open/BCS Compliant

For more information, contact: Mike Meagher, SL Corporation, 240 Tamal Vista
                        Boulevard, Corte Madera, CA  94926, USA Phone: (415)
                        927-1724; Fax: [phone]


Sunrise Software International                                  (Updated:  May
1 992)

Sunrise Software International's product, ezx, is a rapid application
development tool that automates the creation of graphical user interfaces for
OSF/MOTIF and generates C, UIL, or Ada.  ezx provides WYSIWYG screen layout;
color, font and pixmap editors; presentation tools and dialog management.  A
prototype can be developed in hours and using a script language similar to
Hypertalk, demonstrated to end-users before the first line of code is written.
Then portable C, UIL or Ada can be generated automatically.  Ada bindings are
provided.  The total code required to develop a GUI is reduced by
approximately 75%.   The appearance and behavior of the GUI is defined in an X
resource file which the application loads at run time.  This provides explicit
separation between the GUI and the computational core of the application. Thus
the GUI can be revised without recompiling (and retesting) the application.

ezx provides cost savings throughout the software development cycle, from
requirements analysis through design, code, test and maintenance.


Host/Target:DEC RISC under ULTRIX, DEC VAX under VMS, IBM 386 under UNIX, IBM
            RS 6000 under AIX, SGI under , SUN SPARC under UNIX

For more information, contact:Frederick Sells, Sunrise Software International,
                        170 Enterprise Center, Middletown, RI  02840, USA;
                        Phone:  [phone]

Systems Engineering Research Corporation (SERC)            (Updated:  November
1 992)

SERC's Ada/MOTIF is a complete binding to X Window and OSF/Motif for the Ada
programming language that was based in part upon the SAIC/Unisys (STARS)
public domain bindings.  That work was leveraged as a starting point for this
development; many of the bug fixes and additional capabilities beyond the
public domain releases in Ada/MOTIF have been incorporated.  Most noteworthy
are the capabilities included in Ada/Motif for Ada tasking, callback
registration, memory leak detection/prevention and capabilities for developing
customized widgets.  Paramax/STARS considers Ada/Motif to be the commercial
version of their STARS bindings, according to SERC.

Ada/MOTIF is supported by the ALSYS, VERDIX, SUNAda, IBM Ada, and SGI Ada
compilers.


Host/Target:SUN 4, HP 300/400, HP 700, IBM RS 6000, SGI, 386
            SUN OS 4.1.1, SOLARIS 2.0 (coming), HPUX 8.0, SGI 3.2 & 4.0, IBM
            ATX 3.2, SCO 3.2

For more information, contact:Theo Kusiolek or Scott Cleveland, Systems
                        Engineering Research Corporation (SERC), 2555
                        Charleston Road, Mountain View, CA  94043, USA; Phone:
                        800-ADA-SERC or 415/962-9092; Fax:  [phone];
                        E-mail:  Well![e-mail].


TeleSoft                                                   (Updated:  November
1 992)

TeleSoft's TeleUSE/Ada automates the creation of OSF/Motif graphical user
interfaces for Ada applications.  It includes a special version of the TeleUse
User Interface Management System -- which generates Ada source code -- and Ada
bindings to the TeleUSE run-time routines.

TeleUse/Ada tools allow a GUI to be prototyped and designed using a WYSIWYG
editor and a PDL, and also includes tools for debugging, generating production
code and maintaining the GUI.  TeleUse/Ada can save the developer up to 90
percent of the time required to hand code X Window System GUIs.

Host/Target:SPARC under UNIX, Sun-4 under UNIX


TeleSoft's TeleWindows is a set of Ada bindings to the X Window System and
OSF/Motif.  This includes Xlib, XT, X extensions Library, XT+, X miscellaneous
utilities, Motif widget set, XM, MWM, Motif resource manager.  It supports X-
11 R4 and is not based on the public domain version.  It closely follows the C
Xlib syntax and allows Ada applications to co-exist with C applications.

Host/Target:IBM System/370 under VM/CMS

For more information, contact:Karen Johnson, TeleSoft, 5959 Cornerstone Court
                        West, San Diego, CA  92121-9891, USA; Phone:  (619)
                        457-2700

Verdix                                                          (Updated:  May
1 992)

The Verdix Ada Development System (VADS), is a complete Ada Compiler System
offering a fully validated Ada compiler with chapter 13 support.  Verdix
supplies VADSself and VADScross.   VADSself provides a complete toolset for
self-targeted applications.  It easily interfaces to databases, windowing
systems and program management tools.  VADScross provides real-time support
for host-to-target system development.  VADScross produces small and fast
object code.  VADS is hosted on the largest number of platforms and targets
the greatest number of microprocessors.

Host/Target:88000 BCS under UNIX, DEC VAX under VMS / ULTRIX / UNIX,
            DECStation (RISC) under UNIX, DECSystem (RISC) under UNIX, HP 9000
            Series 300 under HP-UX  (UNIX), IBM PS/2 under AIX  (UNIX), IBM
            RISC System/6000 under AIX, SCO Systems V/386 (ABI) under UNIX,
            Sun SPARC systems under UNIX, Sun-3 systems under UNIX

Verdix AXI provides an Ada binding to the full Motif, Xt, and Xlib libraries.
The product works with user-supplied Motif 1.1 and X11R4 libraries regardless
of source.

Host/Target:DEC RISC under Ultrix, IBM RS6000 under AIX, MIPS under MIPSos,
            Sun-4 under SunOS, Sys V386 under ISC UNIX, Sys V386 under SCO
            UNIX

For more information, contact:Tim Ruhe, Verdix Corporation, 205 Van Buren,
                        Herndon, VA  22070, USA; Phone:  [phone]

Answer: Integrated Computer Solutions, Inc. (ICS) supplies Ada bindings to
Motif for a number of platforms and Ada compilers.  ICS also provides Builder
Xcessory, a Motif interface builder, which outputs Ada code usable with the
Ada bindings.  The product family is known collectively as the Ada Xcessories.

Integrated Computer Solutions, Inc. (ICS) 201 Broadway, Cambridge, MA  02139
USA [e-mail]   617/621-0060



-----------------------------------------------------------------------------
Subject: 112)  Is there a Poplog binding for Motif?

[Last modified: May]

Answer:
 A integrated programming environment consisting of the programming
    languages Pop-11, Prolog, Standard ML, and Lisp which are compiled
    to machine code via a common virtual machine. Pop-11 provides a rich
    interface to the X Toolkit which can be accessed from all other
    Poplog languages. The OLIT, Motif, and Athena widget sets are
    supported, in addition to the custom Poplog (Xpw) widget set. XVed
    provides a sophisticated, customisable multi-window editor. Under
    OPEN LOOK and Motif the Poplog User Interface (PUI) provides a
    graphical interface to the Poplog system. High-level Pop-11
    libraries allow graph drawing, turtle graphics, and the simple
    creation of basic button/menu based interfaces.

Contact:

    UK EDUCATION SITES:
        Poplog Sales. School of Cognitive and Computing Sciences.
        Brighton. BN1 9QN. England.
        Phone: [phone]
        Email: [e-mail]
    USA AND CANADIAN EDUCATION SITES:
        Computable Functions Inc. 35 South Orchard Drive. Amherst.
        MA 01002. USA.
        Phone: [phone]
    ALL OTHER SALES:
        Integral Solutions Ltd. Unit 3, Campbell Court. Bramley.
        Basingstoke. Hampshire. RG26 5EG. England.
        Phone:  [phone]
        Fax:    [phone]
        Email:  [e-mail]



-----------------------------------------------------------------------------
Subject: 113)  TOPIC: SPECIFIC PLATFORMS

-----------------------------------------------------------------------------
Subject: 114)  Is it easy to build Motif for a Sun?

Answer: See next question for Solaris 2.  No pattern has emerged to problems
about compiling Motif on the Sun (although people seem to have a lot of
different minor problems), and many reports are that it is straightforward.
Read the Motif install instructions (which often have specific reference to
Sun installation), light the blue touch paper and just standback. [My
experience was that I had to add -D_NO_PROTO for 1.1 on a Sparc OS 4.1, and
that was all.  Others have added STRINGS_ALIGNED and NO_REGEXP].


-----------------------------------------------------------------------------
Subject: 115)  How do I build Motif 1.2.2 on Solaris 2.1 with Sun C?

[Last modified: May 93]

Prepared by Ric Steinberger.  [e-mail]  4/09/93

What follows is a description of the steps I used to build Motif 1.2.2 on a
SUN IPX running Solaris 2.1.  Sun's C compiler (2.0.1) was used.  Many thanks
go to Kaleb Keithley ([e-mail]) for several useful
suggestions.  Other people, including OSF staff, especially David Brooks
([e-mail]), helped as well.  My thanks to you all.

1. Build X11R5 from the mit distribution.  You need to retrieve the sources
   from export.lcs.mit.edu (in pub/R5) and patches 1 - 22 (or 23) (in
   pub/R5/fixes).  There are several other sites that contain the X11R5
   sources.  After installing patch 19, apply PEXlib.tar.Z, also available
   from export.lcs.mit.edu in pub/R5/fixes.  You can apply also
   R5.Xsun.multi-screen and R5.SunOS5.patch.  There are .README files
   that explain how to patch.  Be SURE to read
   R5.SunOS5.patch.README for details on how to BUILD X11.  You probably
   want to use the ProjectRoot feature in the site.def file in the
   mit/config directory.  You will NEED to edit that file to do that.

2. Obtain the Motif 1.2.2 distribution from OSF (617-621-7300).  You may
   need to first install the 1.2 tape, then the 1.2.1 and finally the
   1.2.2 tape.  You might want to do a "chmod -R u+w ." after unloading
   each tape.

3. In the config directory, there are several changes.  Some of the changes
   are based on R5.SunOS5.patch files.  A complete set of config files
   relevant to Solaris have been placed in the anon-ftp account of
   updike.sri.com in pub/motif/solaris21-motif122-config.tar.Z.  They are
   also available from OSF on their mail response server (available to
   support contract holders) and they will send them directly to full
   support contract holders.  Decompress and untar this file in your Motif
   config subdirectory.  Copy site.def.sample to site.def, then edit
   site.def.  You will probably want to uncomment the ProjectRoot section
   and use the same value used in your X11R5 build.  Also, you will probably
   want to use /usr/ucb/install in you installed the UCB compatibility
   suite.  Otherwise you might want to use the install supplied at the end
   of this memo.  [I used the UCB version and can't swear that this works.
   Bit it should.  Put it someplace like /usr/local/bin and chmod +x it.]

   There are two patches to consider.  One fixes a cursor problem
   in ./lib/Xm/TextF.c.  The other removes a Berkeleyism.  These
   patches should probably be consider unofficial at present.
   Failure to deal with the Berkeleyism (bzero) means you will need to
   link with -lucb -lelf.  This will probably work, but why bother?
   Furthermore, if you move the Motif binaries to a machine without
   the ucb compatability suite, you won't have the sharable libs you need.

[The actual patches have been censored because they contain OSF source code]

   Patch 1: In TextF.c there are several places _XmTextFieldDrawInsertionPoint
is called. These should be moved two or three lines further down *after* the
"if (!XtIsRealized(tf)) return True;" statement.


   patch 2: The call to bzero in lib/Xm/Visual.c should be replaced by the
equivalent call to memset


    Both these patches can be applied in the ./lib/Xm directory.
    If you don't have the patch program (how did you build X11?),
    you can get it in the vendor/cygnus directory of ftp.uu.net,
    or you can build it from source.  Be sure to get the latest
    version (2.0.12.u8).

4) Use the README-1.2.1 file as a guideline for building motif.  I followed
   directions in the section called, "Using X11R5 Installed Libraries
   and Header Files."  If you make a mistake after your first build
   attempt, copy Makefile.ini to Makefile before retrying.  You may
   need to do this in the config subdirectory too, depending on what
   went wrong.

5) After make Makefiles, do make includes, make depend, then make (or
   as OSF recommends, make -k).  This gets as far as motifshell in the
   demos, which fails to build because O_RDONLY and L_XTND are
   not defined.  O_RDONLY is in fcntl.h (actually <sys/fcntl.h>, but
   fcntl.h includes this.)  L_XTND can be replaced by SEEK_END.
   SEEK_END is in stdio.h.  These two fixes will allow motifshell to build.
   Note: many MANY compiler warning messages will be generated during
   the build process.

6) You can go to the demos/xmsamplers directory and do a make there.
   Other demos may build, or not depending on whatever. . . .

7) make install will do the install.  [It will fail at motifshell
   if you don't fix it, as mentioned above.]  You can do a make install
   in demos/xmsamplers if you want these.

8) If running on a SUN (as opposed to an X term), you will (probably) need
   to start openwin with something like:

        openwin -server /usr/X11R5/bin/Xsun


   [You might want to use an alias for this.]
   This fixes an annoying problem: The mouse keys stop working after you
   click on an icon to get the icon menu (on SUNs only, not X terms).
   The ALT keys still work, if you get stuck.  I don't know whether this
   is a bug in SUN's server or whether it is Motif related.

   Here is a copy of my .xinitrc:  It's not elegant.  Sun's default
   openwin startup file is in: /usr/openwin/lib/Xinitrc.  You can
   copy this to ~/.xinitrc and customize as desired.  Obviously, the
   default behavior is to start the OpenLook environment (boo!).


#!/bin/sh
#
# .xinitrc - OpenWindows startup script.
#
if [ -f $HOME/.Xdefaults ]; then
    xrdb $HOME/.Xdefaults              # Load Users X11 resource database
fi
if [ -f $HOME/.Xdefaults.sun ]; then
    xrdb -merge $HOME/.Xdefaults.sun
fi
DISPLAY=`hostname`:0.0
export DISPLAY
xhost + > /dev/null
#xterm -sb -sl 512 -T `hostname` -ls -n `hostname` &
xterm -sb -sl 512 -T `hostname` -n `hostname` &
mwm &
xclock -geometry +1010+0 &
xload -geometry +710+5 -fg red &
xsetroot -solid salmon &
xterm -sb -sl 100 -T CONSOLE_DO_NOT_LOGOUT -C -n console -iconic
#wait

Here's .Xdefaults.sun, which gives me a more readable font for use with
motif on Sun monitors:

!Some additional .Xdefaults values specifically for SUN
!
! After loading .Xdefaults, xrdb -merge .Xdefaults.sun
!
Mwm*fontList:           8x16
!Mwm*fontList:          vtbold
!Change as desired.


     You will probably want to maintain LD_LIBRARY_PATH to something like:
/opt/SUNWspro/lib:/usr/ccs/lib:/usr/ucblib:/usr/X11R5/lib:/usr/lib:
/usr/openwin/lib.  If you use emacs, you will need to leave /usr/openwin/lib
there.  [This is because you probably, like me, used the distributed version
of s-sol2.h, which explicitly refers to windowing libraries as being in the
/usr/openwin locations.  Yes, I know that emacs/Solaris ought to allow
LibXt.so.N.M to be "picked up" from elsewhere, like /usr/X11R5/lib, but the
one emacs links with is LibXt.so.4.something, and the mit one is
LibXt.so.5.something.  So it seems to want the .4 one.  Any comments?  I'd
prefer not to rebuild emacs based on the X11R5 libs because I occassionally
need to move the emacs binaries to machines without the mit files.]

-----------------------------------------------------------------------------
Subject: 116)  What compile errors/warnings might I get in both Sun 3 and Sun
4?

Answer:


make: Warning: Too many rules defined for target
make: Warning: Too many rules defined for target
"callbacks.c", line 1530: warning: illegal combination of pointer
and integer, op =
"callbacks.c", line 1531: warning: illegal combination of pointer
and integer, op =
"callbacks.c", line 1532: warning: illegal combination of pointer
and integer, op =
"utils.c", line 73: warning: illegal combination of pointer and integer, op =
"utils.c", line 74: warning: illegal combination of pointer and integer, op =
"utils.c", line 122: warning: illegal combination of pointer and integer, op =
"utils.c", line 123: warning: illegal combination of pointer and integer, op =
"utils.c", line 191: warning: illegal combination of pointer and integer, op =
"utils.c", line 194: warning: illegal combination of pointer and integer, op =
"utils.c", line 195: warning: illegal combination of pointer and integer, op =
"utils.c", line 196: warning: illegal combination of pointer and integer, op =
"utils.c", line 316: warning: illegal combination of pointer and integer, op =
"utils.c", line 334: warning: illegal combination of pointer and integer, op =
"utils.c", line 338: warning: illegal combination of pointer and integer, op =
"utils.c", line 341: warning: illegal combination of pointer and integer, op =
"xmdialogs.c", line 838: warning: illegal combination of pointer
and integer, op =
"xmeditor.c", line 1152: warning: illegal combination of pointer
and integer, op =

These warning messages can be ignored. OSF is aware of these warnings.


-----------------------------------------------------------------------------
Subject: 117)  On a Sun 3, what are the mwm startup error messages about?  I
get

mwm: Invalid accelerator specification on line 7 of
     specification string
mwm: Invalid accelerator specification on line 31 of
      configuration file


Answer: This is because some Sun keyboards do not have an F10 key and some sun
workstations which have an F10 key do not have X-servers which recognize it.
The F10 key is used by mwm.  If the machine does have an F10 key, the user
should use xmodmap to tell the server it exists.  Otherwise, change the
definition of the DefaultWindowMenu in /usr/lib/X11/system.mwmrc (after
installation) or in /lib/clients/mwm/system.mwmrc (before installation).
Change the accelerator of "Maximize" (it is "Alt<Key>F10)" to something else.
Also, you should change the definition of DEFAULTSYSTEMMENU in the file
/clients/mwm/WmResource.c in a similar fashion.  There is as yet no standard
redefinition for F10.



-----------------------------------------------------------------------------
Subject: 118)  Are there problems making shared libraries on a Sun?

Answer: If you use the -pic option you may run out of offset table space.  use
the -PIC option instead.

You may get the message "ld.so: Undefined symbol: __XtInherit" when executing
UIL. There is a problem in shared library build when you compare a function
variable to a routine name, but don't call the routine.  Either, you can build
the Xt library nonshared, or you can put a reference to XtToolkitInitialize in
the UIL main program (or even include a module that references it).  The
routine doesn't even have to be called; it just has to be there.


-----------------------------------------------------------------------------
Subject: 119)  The OpenWindows server hangs when I popup a menu with Button 3.
[Last modified: August 92]

Answer: This is an OpenWindows problem, but if you have Motif source you can
fix your own applications. From Steve Sistare of Thinking Machines Corp.:
"Change the 2 calls to XtGrabButton in RowColumn.c such that ButtonReleaseMask
| ButtonPressMask is passed for the event mask.  Currently, only
ButtonReleaseMask is passed.  Also, change the owner_event argument to FALSE.
" This has not been fixed in Motif as at 1.1.5.

-----------------------------------------------------------------------------
Subject: 120)  Has anyone made shared libraries on an IBM RS/6000?

Answer: From Sakari Jalovaara: There is a problem: Xm redefines VendorShell
and the AIX linker put _both_ Xm's and Xt's VendorShell into programs.  When
an AIX shared library is created as many references inside the library are
resolved as possible.  If the symbol vendorShellClassRec is defined in libXt
and referenced, say, from a function XtFoo() also in libXt, the "ld" run that
creates the shared library resolves the reference:

        XtFoo() -> vendorShellClassRec

Then I create the Motif library that has its own vendorShellClassRec and an
XmBar() function that uses it; libXm will also contain a resolved reference to
vendorShellClassRec:

        XmBar() -> vendorShellClassRec

Finally, I link a program that uses both XtFoo() and XmBar() and the program
will end up with _two_ independent "vendorShellClassRec"s:

        XtFoo() -> vendorShellClassRec [Xt version]
        XmBar() -> vendorShellClassRec [Xm version]

Instant schizo zaphod mode.  In reality, vendorShellClassRec is not referenced
from functions but from other widget class records.

I can't just pull Vendor.o out from the shared Xt (Vendor.o appears to define
the only external symbols redefined by libXm) because AIX shared libraries
apparently can't contain unresolved external references.  If I take out
Vendor.o I have to take out every other file that uses symbols defined there -
and then files that need those files, etc.  I tried it and ended up with three
or four object files in libXt and the res non-sharable.

I kludged around this by putting all of libXt (minus Vendor.o) into the shared
libXm.  It isn't a pretty solution but it works - and beats having a
statically linked two-megabyte "periodic" demo...


-----------------------------------------------------------------------------
Subject: 121)  What is the error  "Unaligned access in XmString" under Ultrix?

Answer: Compile  XmString.c with STRINGS_ALIGNED.

-----------------------------------------------------------------------------
Subject: 122)  TOPIC: KEYSYMS

-----------------------------------------------------------------------------
Subject: 123)  What is causing the messages "unknown keysym osfDown..."?  It
happens when I run an application under Motif 1.1

Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file.
It is found on the release tape and should have been automatically installed
if the installation procedure was followed in the Release Notes.

You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11.  This may
require root permission.  It is not clear how to fix the problem if you can't
do this.  The error comes from Xt translation table parsing and can't be fixed
in Motif, so if you can't get root permission you may be stuck.  The file is
not copyrighted so you can install it on other systems.

If X has been built so that XKeysymDB is not in this directory, and you don't
know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the
path.

On a Sun running openwin with shared libraries, you may need to put the path
for the library containing XKeysymDB *first* in the path list in
LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory.

XKeysymDB simply contains the registered keysym values for the OSF keysyms.
The OSF values are server-independent.  And, all registered keysyms will be
included in an XKeysymDB file to be shipped with X11R5.

In the meantime (till all systems are X11R5+), a list of the registered
keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry.

Also note the XKEYSYMDB environment variable. Setting this to point to the
XKeysymDB file often helps, but not always...


-----------------------------------------------------------------------------
Subject: 124)  What happens if I can't install Motif Keysyms?

From: tessi![e-mail] (George Mitchell)

Here's what appears to happen if you don't have XKeysymDB in place to define
OSF's virtual keysyms:

1. At class initialize time, for a widget (such as XmText) that uses virtual
keysyms in its event translation table, all entries which refer to those
keysyms fail to parse correctly.  In the case of XmText, instead of ending up
with a translation table with roughly 90 entries, you end up with one that has
29.

2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get
translated to plain vanilla keysyms, right?  WRONG!  All Motif widgets install
a virtual keysym translator ANYWAY!  Consequently, the backspace key (for
example) gets translated to the keysym osfBackSpace.

3. Therefore, if you augment or override your widget's translations with
translations that refer to plain vanilla BackSpace, they will never be
triggered, because you will NEVER see plain vanilla BackSpace, only
osfBackSpace.

4. But you can't use osfBackSpace in an event translation entry, because you
don't have XKeysymDB installed!

Here's how I'm "dealing" with the problem right now: Motif installs its
virtual keysym translator by calling XtSetKeyTranslator every time a
VendorShell (or subclass) widget is created.  So every time I create a shell,
I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the
default translator.  No more funny virtual keysyms!  Now I can reinstall non-
osfKeySym translations and have them work the way I expect.


-----------------------------------------------------------------------------
Subject: 125)  Why has OSF introduced Keysyms into Motif 1.1?  They weren't
there in Motif 1.0.

Answer: From: [e-mail]

Virtual Keysyms are meant to provide a consistent keyboard model for Motif
applications running in a heterogeneous environment in which proprietary (i.e.
vendor specific) non-Motif applications may also be running.

First of all, for the sake of the rest of the readers, let's explain why this
is an issue:

It would be lovely if Motif's translation tables could just use the obvious
keysyms predefined by X.  For example, there are keysyms for XK_BackSpace,
XK_Delete, XK_Left, XK_Right, etc.  Shouldn't these be the ones that are used
in our translations?  Unfortunately, the problem is not so simple.  Some
specific examples:

   While most vendors bind XK_BackSpace to the key at the top right
   of the standard keyboard (often engraved with a leftwards
   pointing arrow), not all do.  In fact, some vendors (including DEC)
   bind that key to XK_Delete.

   While most vendors bind the arrow keys to XK_Up, etc, a number of
   vendors (including Sun, on some servers) bind them to function key
   keysyms.

A simplistic solution would require the use of xmodmap to change the offending
bindings.  That would work swell in an all Motif environment.  However, OSF's
goal (not always perfectly achieved) is interoperability.  That is, we'd like
to make sure that both Motif and non-Motif programs can happily run in the
same environment.

It is expected that a vendor may have a wide variety of existing X-based
software that uses the keysyms as established by that vendor for specific
purposes.  It is expected that these applications may run at the same time as
Motif-based software.  Using xmodmap to change keysyms on the server side
could "break" the existing applications (or at the very least their
documentation) by making some keys unavailable, or by moving the location.

So, we chose not to use xmodmap.  By the way, though OpenLook uses a different
implementation (they recompile their virtual translation tables into actual
translation tables), they basically adopted the same approach, presumably for
similar reasons.

To work properly, the virtual keysym model we implemented depends on Xlib
finding XKeysymDB installed appropriately (which standard Motif installation
does).  This simply defines the keysyms (not the key they are bound to).  This
unfortunate piece of stupidity is necessary because MIT only includes standard
keysyms in keysymdef.h.  It should be said that our lives would be made easier
if MIT would also see fit to include registered keysyms in keysymdef.h as
well.

Motif applications determine how to bind virtual to actual keys by looking for
either a resource or a property on the root window which describes what to do.
Note that this information is on the server side, so that all applications use
the same virtual bindings regardless of where they are running.  Mwm will
happily create the property if it finds a .motifbind file in your home
directory when it starts up.  (Actually, things generally work even if none of
this is done, since if all else fails, the Motif toolkit chooses a virtual
bindings table to use based on the identification of the server).

The actual implementation of virtual keys is made possible by a hook in the
Intrinsics.  Undoubtably, the implementation would be simpler and cleaner if
virtual key support was more directly supported by the Intrinsics.  We will be
exploring this possibility in the future.

  -- Ellis

-----------------------------------------------------------------------------
END OF PART FOUR
--
..........................